A plurality of devices and software services are often connected to or reachable within a local network. In order for the plurality of devices to interact, these devices and services need a way to discover each other and communicate with each other. For example, multiple devices exchange particular messages with each other to facilitate a multi-player game, control of one device by another device, content sharing between devices, performance of printing services, etc.
Protocols such as multicast Domain Name System (mDNS) and Universal Plug and Play (UPnP) allow devices on a local network to discover one another and communicate in a limited fashion. DNS-based service discovery (DNS-SD) is used in conjunction with mDNS to discover services. In accordance with DNS-SD, devices use DNS messages to advertise service instance names. A device offering services publishes details of available services: instance, service type, domain name, and optional configuration parameters. A client device stores a service name in a persistent way to access the service, and perform a DNS query for the host name and port number when it's time to connect. While mDNS is focused on discovery, mDNS also provides a notification function for passing a small amount of information between devices. Significant effort on the part of the developers, however, is needed to develop an application that utilizes the discovery and messaging provided by mDNS. Moreover, mDNS is focused on finding a uniquely named instance of a service, which can be cumbersome and limiting for programmers. Service-based communication is limited because a service must be strictly defined to enable a specific function. For example, communication with a print service must convey data in a specific way the corresponding service understands in order to achieve the intended result of printing a document. Also, mDNS includes restrictions associated with the messaging, such as length of the message etc.
Similarly, Simple Service Discovery Protocol (SSDP) is used in conjunction with UPnP for service discovery. In accordance with SSDP, devices use Hypertext Transfer Protocol (HTTP) notification announcements that contain Uniform Resource Identifier (URI) service-types and Unique Service Names (USN). A first device retrieves a description of a service offered by a second device. The UPnP description for a device includes vendor-specific, manufacturer information and, for each service, the description includes a list of the commands, or actions, to which the service responds, and parameters, or arguments, for each action. The first device can send actions to the second device's service by sending a suitable control message to the control Uniform Resource Locator (URL) for the service. Developers, however, still need to develop software to enable the described discovery and communication. Much like mDNS, UPnP/SSDP is developed around the concept of finding uniquely named instances of an entity and has some limitations on the size of the message.
Standards/protocols such as mDNS/DNS-SD and UPnP/SSDP facilitate the discovery of services within the IP network. The approach that mDNS and UPnP take to enable discovery and messaging is centered around the concept of finding a uniquely named instances of an entity/service. This can be burdensome to creative producers and developers of interactive application who are focused on creating unique user experiences. Additionally, for such a standardized solution, a discovered service is either useful or not (to a client) depending on whether it supports a given communications protocol and capabilities. For example, suppose a client has discovered an LPR ‘printer’ service by way of mDNS/DNS-SD. The service conveys, via a DNS-TXT record, that it supports PostScript data. The client, having discovered the service, may now engage the service to print an image.
For example, suppose a client has discovered a “Printer:1” device by way of UPnP/SSDP. This device supports the required service “PrintBasic:1.” The Extensible Markup Language (XML) Service Description offered by the device for the “PrintBasic:1” service indicates that it can print a .png format image. The client, having discovered the service, may now engage the service to print an image. These standardized solutions do not fulfill a need for arbitrary communications between a discovered service and a client.
Efforts to standardize a single protocol have not succeeded, leaving both mDNS and UPnP in continued, predominant use. As a result, a developer of an application or device often chooses one or the other protocol. Choosing one protocol limits that application or device to discovering and communicating only with other applications or devices that use the same protocol. Once a developer has chosen a protocol, the developer delves into the chosen protocol and creates the necessary software to enable discovery of other devices and communication between devices. If the developer chooses to work with both protocols, the effort to create software to enable discovery and communication with each of the protocols is even more labor-intensive and complex.
Other existing technologies enable arbitrary communication between devices but such technologies are facilitated by transmission of data to back-end servers over the internet which then forwards them to other devices as needed. This communication is neither efficient nor cost-effective as messages may travel the globe before being transmitted to a device six feet away. Furthermore, some devices on the local network, such as printers, may not have internet access.